搜索客，搜索人自己的社区

Easysearch analysis-ik 多词典性能优化：从性能回退到分词性能提升 25%~30%

Easysearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 7 次浏览 • 14 分钟前 • 来自相关话题

Easysearch 版 analysis-ik 相比开源 [IK](https://github.com/infinilabs/analysis-ik) 有一个重要的增强：支持多词典。简单说就是不同字段可以挂不同词库，可以叠加默认词典，也可以只用自定义词典。这是开源单词典 IK 做不到的。

功能实现初期，主要精力放在把能力跑通上。但在后来的一次写入压测中，我们发现 Easysearch 的写入吞吐和 Elasticsearch 有明显差距，最终定位到问题出在多词典的实现方式上——字段最终该用哪套词典，本来应该在分词前就算好，结果代码里把这个选择丢进了分词的热路径，每次分词都要反复切词典、重复扫同一段文本。

这篇文章记录的就是我们怎么一步步把性能拉回来、最终反超基线的过程。

问题怎么冒出来的

4 月 20 号，我们跑了一轮系统级写入压测。数据、mapping、settings、并发和 bulk 参数都一样，Elasticsearch 8.19.5 和 Easysearch 2.1.2 的写入吞吐差距大得有点不对劲：

| 时间 | 场景 | Elasticsearch | Easysearch | 说明 |
| :------------------------- | :----------------------------------------------------- | --------------: | -------------: | :---------------------------------------------------- |
| 2026-04-20 第 2 次有效重跑 | 29900 docs / bulk=250 / concurrency=3 端到端写入压测 | 129.44 docs/s | 31.21 docs/s | 这是整条写入链路的 docs/s，不是单独分词吞吐 |
| 2026-04-20 诊断样本 | 5000 docs / bulk=250 / concurrency=3 | 156.25 docs/s | 30.67 docs/s | Easysearch 的累计索引耗时约为 Elasticsearch 的 8.0x |

![](https://infinilabs.cn/img/blog ... ut.svg)

当时服务器上跑的就是早期多词典版本。后面修性能，追的就是这个版本和开源单词典 IK 基线之间的差距。

这一步还不能直接确定问题就在分词器。但差距摆在这儿了，得继续往下排。我们先排除了几个常见干扰因素：

refresh_interval
动态同义词 HTTP 服务
mapping / settings 不一致
网络层和 bulk 客户端本身

采样结果很快把范围收窄了。Elasticsearch 那边热点比较分散，Easysearch 这边呢，分词链路里出现了异常集中的开销——分词过程中反复做词典选择和字典查找。

瓶颈不在 Lucene 写入链路本身，就在 analysis-ik 的多词典实现上。

根因分析

第一类问题出在实现模型上。多词典想表达的是”这个字段最终用哪套词典”，这件事完全可以在分词前算好。但早期代码里，硬是把它变成了运行时的事：
“字段用哪个词典”变成了”运行时多轮扫描”——同一段文本对着多套词典各来一遍。
全局字典切换的动作放进了每字符的热路径。
结果就是同一段文本的扫描和查找成本翻了好几倍。

所以问题不是多词典天然慢，是实现把本该提前算好的东西塞进了热路径反复做。

第二类问题是后续优化过程中留下的额外开销。后面加的跨边界、停用词、长文本等测试本身不是性能问题的来源，它们的作用是把正确性边界补齐，确保每次优化不会改变分词结果。

最后通过性能分析确认，残留开销主要来自两处：缓存命中前还在做不必要的数据复制；诊断逻辑在生产热路径上产生了额外开销。修完之后这两处热点都从火焰图上消失了，说明性能回退确实来自真实的代码路径成本，不是测试抖动。

修复过程

整个修复分四个阶段。

第一阶段：把多词典从”运行时分发”收敛为”最终有效词典视图”

多词典能力保留，但不再让分词器在热路径里反复切词典、重复扫文本。改成在分词前就把字段最终生效的词典算好，分词过程只面对一个已经收敛好的词典视图。

说白了就是把模型拉回正确方向——多词典管表达能力，热路径只管分词。

第二阶段：逐步打掉热路径上的常数开销

留下来的每一项优化，都经过正式性能测试和采样分析验证。原则就一条：不改分词语义，只减少热路径上反复发生的查找、分配和判断。

第三阶段：补齐正确性护栏

正确性测试必须先到位，不然吞吐提升没有意义——万一分词结果变了，跑得再快也白搭。

这一轮重点覆盖了这些容易出问题的场景：
真跨边界场景
数字和量词合并，如 1号
自定义词典里的含符号词
补充平面字符跨边界稳定性
停用词过滤后的偏移量
长文本样本的稳定性
正式性能测试数据集的分词结果对齐

后面所有的吞吐数字，前提都是分词结果一致，避免把分词行为的变化误当成性能提升。

第四阶段：清理最后的残留开销

到 4 月 28 号，最后一轮修复集中处理两个地方：
词典视图命中缓存时直接返回，不再多做一次数据复制
诊断逻辑默认关掉，不让线上请求为调试能力买单

这两处修完，Easysearch 版 IK 就不只是恢复到单词典版本附近了，在正式测试里已经明显领先。

用数据看恢复过程

为了不把系统级写入压测和分词器性能测试混在一起，下面只看几个关键节点。2026-04-20 的 docs/s 是系统级写入吞吐，后面的 tok/s 是单独的分词器吞吐。

这里说的”开源 IK 基线”就是开源 IK 的单词典实现对照版本。所有正式吞吐结论都建立在同一数据集、同一测试方法、分词结果一致的前提上。

| 时间 | 口径 | 关键结果 | 说明 |
| :------------------------------- | :------------- | :-------------------------------------------------------------- | :---------------------------------------- |
| 2026-04-23 17:02 CST | 初期本地复现 | 服务器多词典版本 61.39 万 tok/s，单词典版本 114.48 万 tok/s | 单词典版本快 86.49%，性能差距被明确复现 |
| 2026-04-24 09:51:12~09:55:15 CST | 第一次正式追平 | smart 相对开源单词典基线 +7.26% | 从明显落后追到略微领先 |
| 2026-04-25 04:14~04:16 CST | 双模式阶段复核 | smart +16.88%，max_word +20.09% | 领先优势开始扩大 |
| 2026-04-28 12:30:56 CST | 最新正式复核 | smart +30.96%，max_word +21.31% | 当前最新结果 |

整个过程就是：
先暴露出明显的性能退化
逐步缩小差距
追平，然后开始领先
最终在分词结果完全一致的前提下，正式反超

最早的本地复现数据很关键：服务器当时跑的多词典版本只有 613896.67 tok/s，单词典版本 1144843.77 tok/s。后面所有修复就是冲着这个差距去的。

![](https://infinilabs.cn/img/blog ... rt.svg)

![](https://infinilabs.cn/img/blog ... ry.svg)

三张图分别对应问题暴露、分词复现和修复结果：第一张展示服务器 bulk 写入吞吐的系统级差距；第二张展示多词典版本和单词典版本的本地分词差距；第三张展示分词结果对齐后，Easysearch 版 IK 怎么一步步追上来，最终实现 25%~30% 的分词性能提升。

为什么说 Easysearch 版 IK 现在更好

这次修复的价值不只是消灭了几个热点，更重要的是把多词典能力、分词正确性和性能测试体系一起补齐了。

1. 功能更强，性能代价可控

开源单词典 IK 模型简单，但表达能力也弱。Easysearch 的多词典能力要解决的是字段级词库隔离、自定义词典叠加这些实际需求。

关键问题是：能不能把这些能力的性能开销压到足够低。修复后的结果证明，可以。

2. 正确性护栏更完整

这轮补上的测试不只是几个短样例，覆盖了更容易翻车的边界条件：
真跨边界场景
长文本稳定性
自定义词典和符号词
数字量词合并
停用词过滤后的偏移量

这意味着以后再做性能优化，必须同时保证分词结果不变。想靠改分词行为换吞吐，测试会先拦住。

3. 性能测试体系更严格

这轮之后，Easysearch 对 analysis-ik 的正式性能结论统一按一套标准出：
同一数据集
同一测试方法
smart 和 max_word 双模式
分词结果一致
有性能分析结果支撑

这套体系能避免两个常见坑：只看单轮吞吐波动就下结论，或者分词结果已经变了还在比性能。

小结

多词典能力在实现初期，主要精力放在功能补齐上——先把字段级词库隔离、自定义词典叠加这些能力跑通，性能优化是后面分阶段来的事，没办法一蹴而就。

这轮优化下来，核心思路其实就一条：把词典选择从分词热路径里挪出去，提前收敛好，让分词过程只面对最终的词典视图。再配合热点清理和正确性护栏，增强功能和更高性能完全可以兼得。

截至 2026 年 4 月 28 日，在本地 Mac 笔记本上的多轮 benchmark 中，Easysearch 版 IK 在 smart 模式大约领先开源单词典 IK 基线 25%~30%，max_word 模式大约领先 20% 左右，分词结果完全一致。具体数字每次跑会有波动，但趋势是稳定的。

这也是 Easysearch 版 IK 相对开源版更有价值的地方：不是多了几个配置项，而是在多词典能力、分词正确性和分词性能三个方面都给出了可验证的结果。

关于 Easysearch

![](https://infinilabs.cn/img/blog ... er.png)

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网：<https://easysearch.cn>;

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

---

相关文章：
[开源 IK 分词器](https://github.com/infinilabs/analysis-ik)
[IK 字段级别词典的升级之路](https://infinilabs.cn/blog/202 ... rys-3/)
[IK 字段级别词典升级：IK reload API](https://infinilabs.cn/blog/202 ... rys-2/)
[Easysearch 新功能： IK 字段级别词典](https://infinilabs.cn/blog/202 ... narys/)

【搜索客社区日报】第2227期 (2025-05-08）

社区日报 • Fred2000 发表了文章 • 0 个评论 • 271 次浏览 • 3 小时前 • 来自相关话题

【搜索客社区日报】第2226期 (2025-04-29）

社区日报 • kin122 发表了文章 • 0 个评论 • 5813 次浏览 • 2026-04-29 11:00 • 来自相关话题

【搜索客社区日报】第 2225 期 (2026-04-28)

社区日报 • God_lockin 发表了文章 • 0 个评论 • 6617 次浏览 • 2026-04-28 07:08 • 来自相关话题

Easysearch 正式支持插件开发：让你的搜索系统真正"为你所用"

Easysearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 6697 次浏览 • 2026-04-27 22:02 • 来自相关话题

从"用搜索"到"造搜索"

搜索系统的需求千差万别。标准功能覆盖不了所有场景——行业特定的分词规则、定制化的业务逻辑、与外部系统的深度集成……

以往，这类定制需求需要依赖厂商支持。从 Easysearch 2.1.2 开始，你可以自己动手了。

随着构建依赖库正式发布到 Maven 中央仓库，Easysearch 的插件开发能力正式对外开放。这意味着 Easysearch 不再是一个黑盒产品，而是一个可扩展、可定制的搜索平台。你可以基于官方接口开发自定义插件，像使用原生功能一样使用它们。

插件能做什么

Easysearch 提供三类核心扩展点，覆盖搜索系统的关键环节：

![](https://infinilabs.cn/img/blog ... /1.png)

1. 分析器插件（AnalysisPlugin）

自定义分词器、Token 过滤器、字符过滤器。适用于：

电商 SKU 的型号规格解析
医疗、法律等领域的专业术语分词
特殊符号或空格的规范化处理

注册后直接在索引设置中使用，与原生分析器完全等同。

![](https://infinilabs.cn/img/blog ... /2.png)

2. REST/API 插件（ActionPlugin）

新增自定义 HTTP 接口。适用于：
封装业务查询逻辑，对外暴露简化 API
对接企业内部权限中心或监控系统
暴露插件自身的管理接口（如状态检查）

![](https://infinilabs.cn/img/blog ... /3.png)

3. Ingest 插件（IngestPlugin）

在文档写入前进行字段转换。适用于：
自定义业务字段转换（如根据业务规则计算衍生字段）
数据标准化（统一日期格式、大小写转换）
富文本提取或元数据生成

![](https://infinilabs.cn/img/blog ... /4.png)

5 分钟上手

我们准备了[官方模板仓库](https://github.com/infinilabs/ ... mplate)，让你从克隆到运行只需几条命令：

```bash

克隆模板

git clone https://github.com/infinilabs/ ... e.git my-plugin
cd my-plugin

修改包名和类名，编写你的逻辑

...

 **方式一：开发调试——直接运行**  bash

构建插件并运行

./gradlew run

验证插件

curl -s "<a href="http://localhost:9200/_cat/plugins?v"" rel="nofollow" target="_blank">http://localhost:9200/_cat/plugins?v" | grep my-plugin
 **方式二：构建后安装到外部集群**  bash

构建插件

./gradlew build

安装到 Easysearch

bin/easysearch-plugin install file:///$(pwd)/build/distributions/my-plugin-0.1.0.zip

启动验证

bin/easysearch
curl -s "<a href="http://localhost:9200/_cat/plugins?v"" rel="nofollow" target="_blank">http://localhost:9200/_cat/plugins?v" | grep my-plugin
```

完整的开发指南请参考[插件开发文档](https://docs.infinilabs.com/ea ... ugins/)。

设计哲学

Easysearch 插件系统的设计遵循三个原则：

渐进式扩展——从最简单的 Plugin 类开始，按需实现 AnalysisPlugin、ActionPlugin 等接口，不必一次性掌握全部 API。

与原生同等——插件注册的分析器、处理器与系统原生组件在使用方式上完全一致，用户无需关心实现来源。

版本安全——插件加载时校验 easysearch.version，版本不匹配会拒绝加载，避免运行时异常。

从插件到生态

插件开发不只是技术能力的开放，更是产品理念的转变。

你可以将开发的插件发布到 GitHub Releases，通过 URL 直接安装：

![](https://infinilabs.cn/img/blog ... /5.png)

bash bin/easysearch-plugin install <a href="https://github.com/yourname/my-plugin/releases/download/v0.1.0/my-plugin-0.1.0.zip" rel="nofollow" target="_blank">https://github.com/yourname/my ... 0.zip</a> 

我们也欢迎社区贡献。如果你有通用的插件想法，欢迎与我们交流。

结语

搜索系统的最后一公里，只有业务开发者最清楚该怎么走。

Easysearch 2.1.2 的插件开发能力，让你能够自主掌控搜索系统的"最后一公里"。从"用搜索"到"造搜索"，现在你可以让你的搜索系统真正"为你所用"。

---

关于 Easysearch

![](https://infinilabs.cn/img/blog ... er.png)

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网：<https://easysearch.cn>;

【搜索客社区日报】第2224期 (2026-04-27）

社区日报 • Muses 发表了文章 • 0 个评论 • 7060 次浏览 • 2026-04-27 10:24 • 来自相关话题

【搜索客社区日报】第2223期 (2026-04-24）

社区日报 • Fred2000 发表了文章 • 0 个评论 • 8809 次浏览 • 2026-04-24 10:57 • 来自相关话题

【搜索客社区日报】第2222期 (2025-04-23）

社区日报 • Se7en 发表了文章 • 0 个评论 • 9181 次浏览 • 2026-04-23 22:03 • 来自相关话题

INFINI Agent v1.31.0 发布 | 全新 Easysearch 向导：一站式集群拉起与精细化管理

Easysearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 9241 次浏览 • 2026-04-23 18:01 • 来自相关话题

![release](https://infinilabs.cn/img/blog/release/banner.png)

INFINI Agent v1.31.0 带来了本版本最重要的特性——Easysearch 安装向导。用户无需手动编辑任何配置文件，通过图形界面即可完成 Easysearch 集群的安装、配置和日常管理。

Easysearch 安装向导

一键拉起新集群

向导支持开发模式和生产模式两种方式创建 Easysearch 节点。用户只需填写集群名称、节点名称、监听地址、端口、数据目录等基本信息，向导便会自动完成软件下载、JDK 配置、安全证书生成、参数配置、插件安装、节点启动等全部步骤，并实时展示每一步的进度，支持随时暂停和恢复。

![](https://infinilabs.cn/img/blog ... ev.png)

一键加入已有集群

通过粘贴现有集群提供的 Token，向导可自动从目标集群拉取证书、版本、插件等配置信息，完成新节点的安装和接入，全程无需手动复制任何证书文件。

![](https://infinilabs.cn/img/blog ... er.png)
![](https://infinilabs.cn/img/blog ... ss.png)

安装前环境预检

向导在开始安装前会对当前机器进行全面检测，帮助用户提前发现潜在问题：

操作系统和 CPU 架构是否受支持
内存是否满足推荐要求
端口是否已被占用
数据目录磁盘空间是否充足、路径是否可写
系统参数（文件描述符限制、内核 max_map_count 等）是否满足 Easysearch 运行需求
TLS 证书填写后实时校验有效性，包括证书链完整性和过期时间

![](https://infinilabs.cn/img/blog ... ck.png)

TLS 安全证书灵活配置

支持三种证书配置方式，满足不同安全需求：
自动生成：向导一键生成自签名证书，无需任何证书知识
手动上传（共享）：为 HTTP 和节点通信层提供同一套证书
手动上传（分离）：为 HTTP 层和节点通信层分别提供独立证书

![](https://infinilabs.cn/img/blog ... rt.png)

完整的服务生命周期管理

集群建好后，向导提供持续的管理能力：
启动、停止、重启 Easysearch 节点

![](https://infinilabs.cn/img/blog ... st.png)
在线安装和卸载插件

![](https://infinilabs.cn/img/blog ... in.png)
在线编辑配置，包括 easysearch.yml、JVM 参数、日志配置、证书配置

![](https://infinilabs.cn/img/blog ... ig.png)
在线日志排查：内置日志阅读器，支持查看节点日志文件列表，并提供类似 tail -f 的自动滚动功能，无需登录服务器即可快速定位报错。”

![](https://infinilabs.cn/img/blog ... og.png)

网络受限环境支持

针对无法直接访问外网的环境，向导支持配置 HTTP 代理，所有软件包（Easysearch、JDK、插件）均可通过代理下载，并提供连通性测试功能。

![](https://infinilabs.cn/img/blog ... xy.png)

获取新版本

INFINI Agent v1.31.0 已正式发布，欢迎升级体验：
[下载地址](https://release.infinilabs.com/agent/stable/)
[用户手册](https://docs.infinilabs.com/ea ... ement/)

【搜索客社区日报】第2221期 (2025-04-22）

社区日报 • kin122 发表了文章 • 0 个评论 • 9843 次浏览 • 2026-04-22 14:28 • 来自相关话题

【搜索客社区日报】第 2220 期 (2026-04-21)

社区日报 • God_lockin 发表了文章 • 0 个评论 • 10880 次浏览 • 2026-04-21 07:29 • 来自相关话题

【搜索客社区日报】第2219期 (2026-04-20）

社区日报 • Muses 发表了文章 • 0 个评论 • 11324 次浏览 • 2026-04-20 09:53 • 来自相关话题

【搜索客社区日报】第2218期 (2025-04-17）

社区日报 • Fred2000 发表了文章 • 0 个评论 • 13084 次浏览 • 2026-04-17 09:50 • 来自相关话题

同样 15,000 条重规则，Percolate Query 比 Easysearch 慢 21.8 倍 —— Heavy-OR 场景实测

Easysearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 13985 次浏览 • 2026-04-15 16:44 • 来自相关话题

15,000 条 heavy-OR 规则，200,000 条文档，同一台机器：Easysearch 在线规则引擎全流程 11.68 秒，Percolate Query 仅搜索阶段就跑了 254.30 秒——慢了 21.8 倍。

在"规则先存、文档后到"这类场景下，Percolate Query 的延迟会随规则数量和复杂度的增长快速恶化。规则涨到数千条后，每批文档匹配的耗时可以从秒级攀升至几分钟。这类问题换索引参数、调批次大小、精简 DSL，都治标不治本，根子在执行模型本身。

本文通过一组 heavy-OR 基准测试，量化两种方案的实际差距。

测试配置

测试在同一台主机上运行，使用同一套规则文本和文档样本。Percolate Query 的查询条件由相同规则翻译而来，保证两侧规则语义一致。

| 参数 | 值 |
| :------------- | ------------------------: |
| 规则总数 | 15,000 |
| 文档总数 | 200,000 |
| 批次大小 | 10,000 / 批 |
| 重规则数量 | 2,500 条大 OR 热点规则 |
| 单条大 OR 规模 | 随机 50 ～ 500 个 OR 条件 |

测试结果

| 路径 | 用时 |
| :------------------------- | ------------: |
| 纯写入 plain_bulk | 6.025535s |
| 在线规则引擎 rules_only | 11.684568s |
| Percolate Query 搜索阶段 | 254.304583s |

同样 15,000 条规则 + 200,000 条文档

Easysearch
11.68s
在线规则引擎全流程

Percolate Query
254.30s
只算搜索阶段

Percolate Query 比 Easysearch
慢了 21.8 倍
仅搜索阶段就多花 242.62 秒

具体指标：

- Easysearch 在线规则引擎全流程：`11.68s`
- Percolate Query 搜索阶段：`254.30s`
- 差值：`242.62s`
- 倍数：`21.76 倍`
- 每批（10,000 文档）平均耗时：Easysearch 约 `0.49s`，Percolate Query 约 `12.69s`

## 开启规则引擎的增量成本

规则匹配会对写入链路产生多少额外开销，是评估在线规则引擎可行性的重要指标之一。

开启规则引擎的写入增量

纯写入
6.03s
plain_bulk 基线

开启规则引擎
11.68s
基线 6.03s + 新增 5.66s

规则引擎新增成本
仅 5.66s
Percolate 搜索阶段同期耗时 254.30s

与之对比，Percolate Query 仅搜索阶段就需要 `254.30s`。换言之，Easysearch 在线规则引擎把规则匹配叠加进写入流程，新增成本约为 Percolate Query 搜索耗时的 **1/44.9**。

## 只看匹配引擎本体

上一组数据（11.68s vs 254.30s）包含了 Easysearch 的在线写入、bulk 解析和索引处理等通用开销。为了单独衡量规则匹配引擎自身的性能，我们用 Java 直调 JNI 做了一次离线 match，绕过写入链路，只跑规则匹配逻辑。

| 路径 | 用时 |
| :---------------------------- | ------------: |
| Easysearch 纯匹配（JNI 离线） | `5.046934s` |
| Percolate Query 搜索阶段 | `254.304583s` |

只比匹配本身

Easysearch 纯匹配
5.05s
Java JNI 离线直调

Percolate Query
254.30s
搜索阶段

只看匹配引擎本体
慢了 50.4 倍
254.30 ÷ 5.05 = 50.39

这组数据说明两点：Easysearch 的性能优势并非来自写入链路的整合效率，即便剔除通用写入成本，规则匹配引擎本体与 Percolate Query 之间依然存在约 50 倍的差距。

## 为什么 Percolate Query 会慢

根因在执行模型，OR 条件多只是放大器。

每批文档到达时，Percolate Query 都要走完这套流程：

1. 把文档放进临时内存索引
2. 基于规则中的 terms 筛选候选规则
3. 对候选规则逐条验证

以本次测试为例，各阶段耗时分布如下：

- 规则翻译：`9.560294s`
- 规则导入：`7.451857s`
- percolate 搜索：`254.304583s`

搜索阶段是每批文档都必须重新支付的代价。

Heavy-OR 规则在这套流程里两头放大：规则覆盖面广，候选集更难剪掉；单条规则条件多，逐条验证也更重。

Easysearch 规则引擎把规则提前编译好，文档到达后直接匹配，不走这套每批重建的流程，差距就在这里。

---

## 适用场景

以下场景对规则匹配的吞吐和延迟要求较高，是 Easysearch 在线规则引擎的典型适用范围：

- **内容审核**：规则持续增长且复杂度高，需要稳定的处理吞吐，对单批延迟敏感。
- **舆情监测**：热点词、别名、邻近词组合多，规则天然形成大 OR 结构，是 Percolate Query 最容易触及性能瓶颈的场景。
- **广告定向**：人群包条件不断叠加，文档流量高，规则匹配需要足够轻量，避免影响整条投放链路。
- **告警规则**：延迟直接影响告警有效性，规则命中需要尽量贴近文档写入时刻。
- **实时反欺诈**：规则复杂、变更频繁、吞吐高，要求文档到达后立即完成判断。

## 小结

在本次 heavy-OR 基准测试中：

- 相同规则集（15,000 条）和文档量（200,000 条），Easysearch 在线规则引擎全流程耗时 **11.68s**，Percolate Query 仅搜索阶段耗时 **254.30s**，相差 **21.8 倍**。
- 开启规则引擎带来的写入链路增量成本为 **5.66s**，约为 Percolate Query 搜索阶段耗时的 **1/44.9**。
- 剔除写入通用开销后，规则匹配引擎本体的差距约为 **50 倍**。

如果你的业务已经有 Percolate Query 延迟随规则增长持续上升的问题，不用看 demo 数据——把你线上最重的那批规则拿出来，跑一次就知道差距在哪。

规则引擎功能当前需要试用 License。你可以先下载 Easysearch：<https://infinilabs.cn/download>，再联系售前申请试用 License 并获取开通指引。

## 关于 Easysearch

![](https://infinilabs.cn/img/blog ... er.png)

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：<https://docs.infinilabs.com/easysearch>

> 作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

---

相关文章：

- [Easysearch ZSTD 基准测试：高压缩率下实现近 5 倍查询吞吐](https://infinilabs.cn/blog/202 ... ntage/)
- [Easysearch 2.0.0 性能测试](https://infinilabs.cn/blog/202 ... ments/)
- [Easysearch 时序数据的基于时间范围的合并策略](https://infinilabs.cn/blog/202 ... earch/)
- [Easysearch Rollup 相比 OpenSearch Rollup 的优势分析](https://infinilabs.cn/blog/202 ... ollup/)
- [Easysearch Rollup 使用指南](https://infinilabs.cn/blog/202 ... ollup/)

【搜索客社区日报】第2217期 (2025-04-15）

社区日报 • kin122 发表了文章 • 0 个评论 • 13887 次浏览 • 2026-04-15 13:25 • 来自相关话题

通知设置 新通知

发现

问题怎么冒出来的

根因分析

修复过程

第一阶段：把多词典从”运行时分发”收敛为”最终有效词典视图”

第二阶段：逐步打掉热路径上的常数开销

第三阶段：补齐正确性护栏

第四阶段：清理最后的残留开销

用数据看恢复过程

为什么说 Easysearch 版 IK 现在更好

1. 功能更强，性能代价可控

2. 正确性护栏更完整

3. 性能测试体系更严格

小结

关于 Easysearch

从"用搜索"到"造搜索"

插件能做什么

1. 分析器插件（AnalysisPlugin）

2. REST/API 插件（ActionPlugin）

3. Ingest 插件（IngestPlugin）

5 分钟上手

克隆模板

修改包名和类名，编写你的逻辑

...

构建插件并运行

验证插件

构建插件

安装到 Easysearch

启动验证

设计哲学

从插件到生态

结语

Easysearch 安装向导

一键拉起新集群

一键加入已有集群

安装前环境预检

TLS 安全证书灵活配置

完整的服务生命周期管理

网络受限环境支持

获取新版本

测试配置

测试结果

同样 15,000 条规则 + 200,000 条文档

开启规则引擎的写入增量

只比匹配本身

活动推荐

热门话题

通知设置新通知